home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / hacklist / 94-04.Z / 94-04 / 000008_rcq@mailserv-D.ftp.com_Sat Apr 9 07:28:38 1994.msg < prev    next >
Internet Message Format  |  1994-04-30  |  3KB
  1. Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA01287; Sat, 9 Apr 1994 11:29:34 -0400
  3. Received: from ftp.com by ftp.com  ; Sat, 9 Apr 1994 11:29:33 -0400
  4. Received: from mailserv-D.ftp.com by ftp.com  ; Sat, 9 Apr 1994 11:29:33 -0400
  5. Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
  6.     id AA19990; Sat, 9 Apr 94 11:28:38 EDT
  7. Date: Sat, 9 Apr 94 11:28:38 EDT
  8. Message-Id: <9404091528.AA19990@mailserv-D.ftp.com>
  9. To: ICH211@ZAM001.ZAM.KFA-JUELICH.DE
  10. Subject: Re: Closing and reusing sockets
  11. From: rcq@ftp.com  (Bob Quinn)
  12. Reply-To: rcq@ftp.com
  13. Cc: Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
  14. Sender: rcq@mailserv-D.ftp.com
  15. Repository: mailserv-D.ftp.com, [message accepted at Sat Apr  9 11:28:14 1994]
  16. Originating-Client: hurricane.ftp.com
  17. Content-Length: 2292
  18.  
  19. >  I got the same reply from FTP Software about "no bind used internally" etc,
  20.  
  21. Specifically, you got it from me, just like Bryan did. :)
  22.  
  23. >  which I actually don't find acceptable. I believe that sample code in a
  24. >  specification should work with all compliant implementations, otherwise the
  25. >  implementation is *not* specification compliant. Since the FTP Winsock.DLL
  26. >  surely has access to all pending connection info it should be able to 
  27. >  determine at bind() time if there is a local address in use, and return 
  28. >  EADDRINUSE if necessary. What I had to do in my code is to have the bind() 
  29.  
  30. I don't disagree, we should be compliant.  What I've described
  31. to you and Bryan is just a fact of life with PCTCP.  Believe me,
  32. I don't like it either.  Don't you think I'd change it if I had
  33. "access to all pending connection info" as you say the WinSock
  34. surely does?  It would be much easier to change it, than to spend
  35. time telling customers how to code around this deficiency.
  36.  
  37. Fortunately, there are very few protocols that require any binding
  38. for clients.  You two have found two of them: rsh and lpr.  I am
  39. sorry you need to do the extra coding for our WinSock.  I will help
  40. you all I can, but the fact is if you want to work on our WinSock
  41. the extra effort is required.
  42.  
  43. >  loop followed by a connect() as it should be, and have another loop around 
  44. >  all this to try a new port if the connect() fails.
  45.  
  46. Our WIN4RPC DLL had to implement its own rresvport() (sp?) function
  47. to get a reserved port number.  To avoid the *SAME PROBLEM* that
  48. you have encountered, our RPC developer used the current time as
  49. a seed into the (pseudo)random() function to get a initial port 
  50. between 512 and 1024 for bind() (and as the DLL progresses, it
  51. increments the port number).  I have yet to hear of a case when this 
  52. has caused a subsequent WSAEADDRINUSE and it is used *heavily*.
  53.  
  54. This is one alternative to the bind()/connect() loop.  I know that
  55. Bryan doesn't like it because there's still a chance that bind()
  56. can succeed and subsequent connect() fail, but I don't think this
  57. is a realistic concern ...and I don't consider myself a gambling man :)
  58.  
  59. Regards,
  60. --
  61.  Bob Quinn                                             rcq@ftp.com
  62.  FTP Software, Inc.                                No. Andover, MA